Курсовые работы

 

1.     ОБЩАЯ ХАРАКТЕРИСТИКА ПРОЦЕССА ПРОЕКТИРОВАНИЯ АСОИУ

 

Современные информационные технологии предоставляют широкий набор способов реализации АСОИУ, выбор которых осуществляется на основе требований со стороны предполагаемых пользователей, которые, как правило, изменяются в процессе разработки. Для теории принятия решений процесс проектирования системы – это процесс принятия проектных решений, направленных на получение версии системы, удовлетворяющей требования заказчика.

Под проектом будем понимать проектно-конструкторскую и технологическую документацию, в которой представлено описание проектных решений по созданию и эксплуатации системы в конкретной программно-технической среде.

Под проектированием системы понимается процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в проект АСОИУ. С этой точки зрения проектирование АСОИУ сводится к последовательной формализации проектных решений на различных стадиях жизненного цикла системы: предпроектного анализа требований, технического и рабочего проектирования, внедрения и эксплуатации АСОИУ.

Осуществление проектирования системы предполагает использование проектировщиками определенной технологии проектирования, соответствующей масштабу и особенностям разрабатываемого проекта.

Технология проектирования системы – это совокупность методологии и средств проектирования системы, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта системы).

В основе технологии проектирования лежит технологический процесс, который определяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий. Технологический процесс проектирования системы в целом делится на совокупность последовательно-параллельных, связанных и соподчиненных цепочек действий, каждое из которых может иметь свой предмет.

Проектирование системы – трудоемкий, длительный и динамический процесс. Технологии проектирования, применяемые в настоящее время, предполагают поэтапную разработку системы. Этапы по общности могут разделяться на стадии. Совокупность стадий и этапов, которые проходит система в своем развитии с момента принятия решения о создании системы до момента прекращения функционирования системы, называется жизненным циклом системы.

Суть содержания жизненного цикла разработки системы в различных подходах одинакова и сводится к выполнению следующих стадий:

Планирование и анализ требований (предпроектная стадия) – системный анализ. Исследование и анализ существующей системы, определение требований к создаваемой системе, оформление технико-экономического обоснования и технического задания на разработку системы.

Проектирование (техническое проектирование, логическое проектирование). Разработка в соответствии со сформулированными требованиями состава автоматизируемых функций и состава обеспечивающих подсистем, оформление технического проекта системы.

Реализация проекта (рабочее проектирование, физическое проектирование, программирование). Разработка и настройка программ, наполнение баз данных, создание рабочих инструкций для персонала, оформление рабочего проекта.

Внедрение (тестирование, опытная эксплуатация). Комплексная отладка подсистем, обучение персонала, поэтапное внедрение системы в эксплуатацию, оформление акта о приемосдаточных испытаниях системы.

Эксплуатация системы (сопровождение, модернизация). Сбор рекламаций и статистики о функционировании системы, исправление ошибок и недоработок, оформление требований к модернизации системы и ее выполнение.

 

2.     РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ МОДЕЛИ АСОИУ

 

          Предпроектная стадия, включающая проведение необходимых исследований, работ по формированию структуры АСОИУ и получение в конечном счете технического задания на проектирование может проходить по двум принципиально различным вариантам.

          Первый – классический фундаментальный подход. Связан с проведением исследований по вскрытию законов, на основе которых функционирует  исследуемая система обработки информации и управления. Далее, вследствие   выявленных фундаментальных законов, строится формальная модель, связывающая входы, выходы системы, влияние внешних воздействий на нее. Таким образом, получаем формально-математическое представление системы, которое и может в дальнейшем служить основой для функционального, инфологического и технорабочего проектирования АСОИУ.

          Второй подход, достаточно часто применяемый при построении АСОИУ, включает в себя проведение информационного обследования объекта (предметной области), выявление основных информационных потоков, построения, как правило, имитационной модели функционирования объекта и далее выход также на инфологическое и технорабочее проектирование.

          Первый подход в большей степени гарантирует получение высококачественной разработки, но требует больших интеллектуальных и финансовых затрат. Второй подход обеспечивает, на первый взгляд, меньшие затраты, но вероятней всего за счет неудачных и малоэффективных решений, общие затраты при реализации работ по второму варианту могут быть и значительно больше, чем в первом случае.

          Однако выбор схемы решения всегда остается за разработчиком.

Далее приводятся некоторые моменты, связанные с использованием структурного анализа.

Структурным анализом SADT (Structured Analysis and Design Technique) принято называть метод исследования системы с помощью ее графического модельного представления, которое начинается с общего обзора и последующей детализации, в иерархическую структуру со все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 9); ограниченный контекст, включающий лишь существенные на каждом уровне детали; дуальность данных и операций над ними; использование строгих формальных правил записи; последовательное приближение к конечному результату.

Анализ является первым этапом создания АСОИУ, на котором требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта.

Структурный анализ начинается с исследования того, как организована система управления предприятием, с обследования функциональной и информационной структуры системы управления. По результатам обследования аналитик на первой стадии анализа строит обобщенную логическую модель исходной предметной области, отображающую ее функциональную структуру, особенности основной деятельности и информационное пространство, в котором эта деятельность осуществляется. Используя специальную терминологию, можно сказать, что аналитик строит модель «как есть».

Вторая стадия работы, к которой привлекаются заинтересованные представители заказчика, а при необходимости и независимые эксперты, состоит в анализе модели «как есть», выявлении ее недостатков и узких мест, определении путей совершенствования системы управления на основе выделенных критериев качества.

Третья стадия анализа, содержащая элементы проектирования, – создание усовершенствованной обобщенной логической модели, отображающей реорганизованную предметную область или ее часть, которая подлежит автоматизации. Эту модель можно назвать моделью «как надо», т.е. здесь происходит  формализация системы.

Наряду со структурным подходом существует и более мощный подход, называемый объектно-ориентированным ООП. Эта методология создана для проектирования больших и сложных систем и имеет ряд преимуществ перед структурным подходом.

ООП базируется на создании объектной модели, которая описывает структуру объектов, составляющих систему, их атрибуты, операции, взаимосвязи с другими объектами. Цель разработки объектной модели – описать объекты, составляющие в совокупности проектируемую систему, а также выявить и указать различные зависимости между объектами. Декомпозиция проблемы на объекты – творческий, плохо формализуемый процесс.

В объектной модели должны быть отражены те понятия и объекты реального мира, которые важны для разрабатываемой системы. В объектной модели отражается прежде всего прагматика разрабатываемой системы, что выражается в использовании терминологии прикладной области, связанной с использованием разрабатываемой системы.

Объектная модель имеет четыре главных элемента: абстрагирование, инкапсуляция, модульность, иерархия.

Эти элементы являются главными в том смысле, что без любого из них модель не будет объектно-ориентированной. Кроме главных, имеются еще три дополнительных элемента: типизация, параллелизм, сохраняемость.

Абстрагирование выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя. Инкапсуляция – это процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение; инкапсуляция служит для того, чтобы изолировать контрактные обязательства абстракции от их реализации. Модульность – это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули. Иерархия – это упорядочение абстракций, расположение их по уровням. Типизация – это способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием. Параллелизм – это свойство, отличающее активные объекты от пассивных.

Сохраняемость – способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства.

 

3.     ИСХОДНЫЕ ДАННЫЕ ДЛЯ ПРОЕКТИРОВАНИЯ

 

Методы, которые используются для изучения предметной области и технологии получения от экспертов сведений о системе, подлежащей описанию, называются сбором данных, а в информатике она больше известна как опрос (интервьюирование) или извлечение знаний. Но как бы она не называлась, способность собрать необходимую информацию, основанную на знаниях экспертов, весьма существенна для построения точной и полезной модели. Поэтому технология сбора информации составляет важную часть структурной методологии SADT.

Опрос – это сбор сведений. Первый опрос служит точкой отсчета в процессе моделирования. Чтобы провести опрос, аналитик вначале выбирает наилучший источник информации (документ или конкретного человека), а затем организует его "опрос". Цель опроса – получение порции информации, необходимой для начала либо для продолжения построения определенной части модели. После первого опроса SADT-модель используется для определения той информации, которую необходимо получить в ходе следующего опроса. В соответствии с иерархией модели может быть проведена последовательность опросов для выяснения все более конкретных деталей рассматриваемой области.

Обычно источниками информации служат эксперты. Часто именно они являются наилучшими источниками, потому что им знакомы текущие нюансы и недокументированные аспекты системы. Самое важное – это то, что экспертам известны факты, которые не отражены в документах или которые трудно объяснить. Их можно получить только путем опроса экспертов. Чтобы подготовиться к такому опросу, нужно исследовать другие источники информации, например документы. Существует множество различных стратегий для извлечения информации из этих источников: чтение документов, наблюдение за выполняемыми операциями, анкетирование, использование собственных знаний, составление описания.       

Документы – хороший источник информации, потому что они чаще всего доступны и их можно "опрашивать" в удобном для себя темпе. Чтение документов – прекрасный способ получить первоначальное представление о системе и сформулировать вопросы к экспертам.

Наблюдение за работой моделируемой системы – хорошая стратегия получения информации. Оно должно проводиться всегда, когда есть такая возможность. Через наблюдение, а возможно, и участие аналитики получают информацию о происходящих день за днем операциях из первых рук. Во время наблюдения за работой системы часто возникают вопросы, которые никогда бы не появились, если бы аналитик только читал документы или разговаривал с экспертами. Однако следует соблюдать осторожность. Слишком долгие наблюдения могут привести к избыточному привыканию к текущему состоянию дел. Из-за потери объективности можно не увидеть альтернативные пути описания функций системы.

Анкетирование проводится для того, чтобы опросить большие группы экспертов в сжатые сроки. Его можно использовать, например, когда необходимо быстро получить сведения о работе какой-либо определенной части системы с разных позиций. Анкетирование при опросе экспертов позволяет выявить, какие части системы более всего нуждаются в улучшении. На практике, однако, информация, полученная от экспертов с помощью анкет, оказывается недостаточно достоверной.

Еще одна полезная стратегия – придумать описание и дать его экспертам для корректировки. Придуманные описания могут дать альтернативные схемы функционирования системы – схемы, о которых эксперты никогда не думали. Однако для реализации таких схем нужна поддержка. Предварительно нужно изучить предметную область и найти хотя бы одну доброжелательно настроенную группу экспертов, прежде чем пытаться придумать описание. В этом. случае описание будет иметь шансы отразить реальность. Придуманные описания могут, однако, потерпеть неудачу, если эксперты не готовы воспринимать новые возможности. В идеале, прежде чем прибегать к этой стратегии, автор должен установить надежные контакты с несколькими экспертами.

Создание и внедрение автоматизированных систем различных классов и назначений ведется во многих отраслях промышленности по нормативно-технической документации, устанавливающей разнообразные организационно-методические и технические нормы, правила и положения, затрудняющие интеграцию систем и эффективное их совместное функционирование.

 

 

4.     ПРОЕКТИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

 

Проектирования интерфейса пользователя – сложная многофакторная и многовариантная задача, требующая системного подхода. В настоящее время считается доказанным, что решение данной задачи заключается не в том, чтобы рационально «вписать» человека в контур управления, а в том, чтобы исходя из задач управления объектом разработать систему взаимодействия двух равноправных партнеров (человек-оператор и аппаратно-программный комплекс АСОИУ).

Цель создания эффективного эргономичного пользовательского интерфейса состоит в том, чтобы отобразить информацию настолько эффективно, насколько это возможно для человеческого восприятия, и структурировать отображение на дисплее таким образом, чтобы привлечь внимание к наиболее важным единицам информации.

Пользователь должен иметь возможность манипулировать объектами в среде приложения. Неплохо, если они (графические элементы) будут ему понятны и станут нести в себе информацию о том, что это такое и что произойдет, если выбрать или произвести действие над каким-то объектом. Иллюстрация этой идеи – панель быстрого доступа Word'a. Что еще, кроме как сохранение файла, можно ожидать от кнопки с изображением дискеты? Необходимо, чтобы пользователь имел наглядное средство отображения информации на различных этапах решения задач, он должен видеть, как его действия влияют на объекты, расположенные на экране.

Создание эффективного интерфейса заключается в быстром, насколько это возможно, развитии у пользователей простой концептуальной модели интерфейса. Концепция согласованности состоит в том, что при работе с компьютером у пользователя формируется система ожидания одинаковых реакций на одинаковые действия, что постоянно подкрепляет пользовательскую модель интерфейса.

Приложение должно проектироваться таким образом, чтобы пользователь в любой момент и на любом этапе работы мог получить помощь, контекстную справку или подсказку.

Безусловно, пользователю нужно дать возможность экспериментировать в приложении (нажатие любых кнопок, изменение настроек и т. д.). Но при этом необходимо избавить его от тупиковых ситуаций: все последствия экспериментов должны быть исправимы, а в лучшем случае еще и обратимы.

Интерфейс должен предоставлять информацию о том, что происходит в данный момент на компьютере. Нельзя допускать, чтобы пользователь долгое время ожидал реакции приложения на некоторое свое действие.

Цветовая гамма, компоновка элементов, пиктограммы, звуки, анимация – все должно помогать пользователю при выполнении задачи. Но здесь важно не переборщить, так как в этом случае внимание человека начнет рассеиваться, у него появится раздражение и, как следствие, снизится эффективность работы.

Начальным этапом разработки пользовательского интерфейса является создание его ассоциативной модели, после чего осуществляется проработка концептуального дизайна. Здесь необходимо разработать необходимый набор интерфейсных элементов, каждый из которых должен обладать определенным цветом, формой, надписью и т. п., и все вместе они должны составлять единую систему, вызывающую стойкую систему ассоциаций у пользователей.

Цвет – мощный визуальный инструмент, который необходимо использовать очень осторожно, чтобы не вызвать неадекватной реакции пользователя.

Целесообразно ограничить число цветов до 4 на экране и до 7 для последовательности экранов. Для неактивных элементов рекомендуется использовать бледные цвета. Необходимо использовать цвета согласно представлениям пользователя. Например, для картографа зеленый цвет – лес, желтый – пустыня, синий – вода. Если цвет используется для кодировки информации, необходимо удостовериться, что код адекватно воспринимается пользователем: красный – опасность/стоп, зеленый – нормально/продолжение работы, желтый – предостережение. Для привлечения внимания наиболее эффективны белый, желтый и красный цвета.

Меню – необходимый элемент любой автоматизированной системы, позволяющий пользователю выполнять задачи внутри приложения и управлять процессом решения. Достоинство меню в том, что пользователи не должны помнить название элемента или действия, которое они хотят выполнить – они должны только распознать его среди пунктов меню.

Сообщения необходимы для направления пользователя в нужную сторону, подсказок и предупреждений для выполнения необходимых действий на пути решения задачи. Они также включают подтверждения действий со стороны пользователя и подтверждения, что задачи были выполнены системой успешно либо по каким-то причинам не выполнены. Сообщения могут быть обеспечены в форме диалога, экранных заставок и т.п.

 

5. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННО-ЛОГИЧЕСКОГОЙ МОДЕЛИ АСОИУ

 

Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий – "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями – "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений – "возраст сотрудника не менее 16 и не более 60 лет".

Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных.

Решения, принятые на предыдущем уровне, при разработке модели предметной области, определяют некоторые границы, в пределах которых можно развивать логическую модель данных, в пределах же этих границ можно принимать различные решения. Например, модель предметной области складского учета содержит понятия "склад", "накладная", "товар". При разработке соответствующей реляционной модели эти термины обязательно должны быть использованы, но различных способов реализации тут много – можно создать одно отношение, в котором будут присутствовать в качестве атрибутов "склад", "накладная", "товар", а можно создать три отдельных отношения, по одному на каждое понятие.

При разработке логической модели данных возникают вопросы: хорошо ли спроектированы отношения? Правильно ли они отражают модель предметной области, а следовательно, и саму предметную область?

Для того чтобы оценить качество принимаемых решений на уровне логической модели данных, необходимо сформулировать некоторые критерии качества в терминах физической модели и конкретной реализации и посмотреть, как различные решения, принятые в процессе логического моделирования, влияют на качество физической модели и на скорость работы базы данных.

Таких критериев может быть очень много и выбор их произволен. Некоторые из таких критериев являются важными с точки зрения получения качественной базы данных: адекватность базы данных предметной области, легкость разработки и сопровождения базы данных, скорость выполнения операций обновления данных (вставка, обновление, удаление кортежей), скорость выполнения операций выборки данных.

База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия.

1. Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.

2. Изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных.

3. Ограничения предметной области, отраженные в модели предметной области, должны некоторым образом отражаться и учитываться в базе данных.

Практически любая база данных, за исключением совершенно элементарных, содержит некоторое количество программного кода в виде триггеров и хранимых процедур.

Хранимые процедуры – это процедуры и функции, хранящиеся непосредственно в базе данных в откомпилированном виде, которые могут запускаться пользователями или приложениями, работающими с базой данных. Основное назначение хранимых процедур – реализация бизнес-процессов предметной области.

Триггеры – это хранимые процедуры, связанные с некоторыми событиями, происходящими во время работы базы данных. В качестве таких событий выступают операции вставки, обновления и удаления строк таблиц. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события, с которым этот триггер связан. Триггер срабатывает независимо от того, кто из пользователей и каким способом инициировал событие, вызвавшее запуск триггера. Таким образом, основное назначение триггеров – автоматическая поддержка целостности базы данных.

Очевидно, что чем больше программного кода в виде триггеров и хранимых процедур содержит база данных, тем сложнее ее разработка и дальнейшее сопровождение.

На уровне логического моделирования определяются реляционные отношения и атрибуты этих отношений. На этом уровне можно определять какие-либо физические структуры хранения (индексы, хеширование и т.п.). Единственное, чем можно управлять – это распределение атрибутов по различным отношениям. Можно описать немного  отношений с большим количеством атрибутов или сформировать большое количество отношений, каждое из которых содержит мало атрибутов. Таким образом, необходимо попытаться ответить на вопрос – влияет ли количество отношений и количество атрибутов в отношениях на скорость выполнения операций обновления данных. Такая постановка вопроса не является достаточно корректной, так как скорость выполнения операций с базой данных зависит от физической реализации базы данных. Тем не менее, целесообразно качественно оценить это влияние при одинаковых подходах к физическому моделированию.

Основными операциями, изменяющими состояние базы данных, являются операции вставки, обновления и удаления записей. В базах данных, требующих постоянных изменений (складской учет, системы продаж билетов и т.п.), производительность определяется скоростью выполнения большого количества небольших операций вставки, обновления и удаления.

Обычно вставка записи производится в одну из свободных страниц памяти, выделенной для данной таблицы. СУБД постоянно хранит информацию о наличии и расположении свободных страниц. Если для таблицы не созданы индексы, то операция вставки выполняется фактически с одинаковой скоростью независимо от размера таблицы и от количества атрибутов в таблице. Если в таблице имеются индексы, то при выполнении операции вставки записи индексы должны быть перестроены. Таким образом, скорость выполнения операции вставки уменьшается при увеличении количества индексов у таблицы и мало зависит от числа строк в таблице.

Для операции обновления и удаления записей из таблицы, прежде, чем обновить или удалить запись, ее необходимо найти. Если таблица не индексирована, то единственным способом поиска является последовательное сканирование таблицы в поиске нужной записи. В этом случае скорость операций обновления и удаления существенно увеличивается с увеличением количества записей в таблице и не зависит от количества атрибутов. Но на самом деле неиндексированные таблицы практически никогда не используются. Для каждой таблицы обычно объявляется один (или несколько) индекс, соответствующий потенциальным ключам. При помощи этих индексов поиск записи производится очень быстро и практически не зависит от количества строк и атрибутов в таблице (хотя, конечно, некоторая зависимость имеется). Если для таблицы объявлено несколько индексов, то при выполнении операций обновления и удаления эти индексы должны быть перестроены, на что тратится дополнительное время. Таким образом, скорость выполнения операций обновления и удаления также уменьшается при увеличении количества индексов у таблицы и мало зависит от числа строк в таблице.

Одно из назначений базы данных – предоставление информации пользователям. Информация извлекается из реляционной базы данных при помощи оператора SQL – SELECT. Одной из наиболее дорогостоящих операций при выполнении оператора SELECT является операция соединения таблиц. Таким образом, чем больше взаимосвязанных отношений было создано в ходе логического моделирования, тем больше вероятность того, что при выполнении запросов эти отношения будут соединяться, и, следовательно, тем медленнее будут выполняться запросы. Таким образом, увеличение количества отношений приводит к замедлению выполнения операций выборки данных, особенно, если запросы заранее неизвестны.

 

 

6. СТРУКТУРА ПРОГРАММНЫХ МОДУЛЕЙ, РАЗРАБОТКА АЛГОРИТМОВ, ЛОГИЧЕСКИЙ АНАЛИЗ СТРУКТУР

 

Современные технологии разработки программного обеспечения информационных систем предполагают большое разнообразие концепций, подходов и методик. Наиболее популярные из них  – структурный и объектный подходы.

Структурный метод, о котором шла речь при разработке информационного обеспечения, при создании программного обеспечения базируется на использовании технологии моделирования потоков данных.

Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой информационной системе. С их помощью эти требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных. Главная цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Диаграммы потоков данных известны очень давно.

В основе методологии (Gane/Sarson) лежит построение модели анализируемой системы – проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы системы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно.

Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются:

·        внешние сущности;

·        системы/подсистемы;

·        процессы;

·        накопители данных;

·        потоки данных.

Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например заказчики, персонал, поставщики, клиенты. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой системы. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой системы, если это необходимо, или, наоборот, часть процессов  может быть вынесена за пределы диаграммы и представлена как внешняя сущность.

Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.

Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например:

·        "Ввести сведения о клиентах";

·        "Выдать информацию о текущих расходах";

·        "Проверить кредитоспособность клиента".

Использование таких глаголов, как "обработать", "модернизировать" или "отредактировать" означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.

Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.

Накопитель данных представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.

Накопитель данных в общем случае является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью.

Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока. Каждый поток данных имеет имя, отражающее его содержание.

Первым шагом при построении иерархии ДПД является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы.

Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и, кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть :наличие большого количества внешних сущностей (десять и более);

·        распределенная природа системы;

·        многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.

Для сложных систем строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.

Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры системы на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в разработке которых участвуют разные организации и коллективы разработчиков.

Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою очередь, может быть детализирован при помощи ДПД или миниспецификации.

Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.

При построении иерархии ДПД переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.

 

 

7. АВТОМАТИЗАЦИЯ ПРОЦЕССА ПРОЕКТИРОВАНИЯ

CASE-СРЕДСТВАМИ

 

Под термином "CASE-средства" (Computer Aided Software Engineering) понимаются программные средства, поддерживающие процессы создания и сопровождения АСОИУ, включая анализ и формулировку требований, проектирование прикладного ПО и баз данных, генера­цию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки АСОИУ.

Появлению CASE-технологии и CASE-средств предшествовали исследования в об­ласти методологии программирования. Программирование обрело черты системного подхо­да с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования.

CASE-технология представляет собой методологию проектирования АСОИУ, а также на­бор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения АСОИУ и разра­батывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в ос­новном) или объектно-ориентированного анализа и проектирования, использующих специ­фикации в виде диаграмм или текстов для описания внешних требований, связей между мо­делями системы, динамики поведения системы и архитектуры программных средств .

Наиболее трудоемкими этапами разработки АСОИУ являются этапы анализа и проектиро­вания, в процессе которых CASE-средства обеспечивают качество принимаемых техниче­ских решений и подготовку проектной документации. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую АСОИУ, перестраивать ее в соответствии с поставленными целями и имеющимися ограничения­ми.

CASE-средства обладают следующими основными особенностями :

а) имеют мощные графические средства для описания и документирования АСОИУ, обес­печивающие удобный интерфейс с разработчиком и развивающие его творческие возможно­сти;

б) осуществляют интеграцию отдельных компонент CASE-средств, обеспечивающую управляемость процессом разработки систем;

в) используют специальным образом организованное хранилище проектных метадан­ных (репозитория).

Интегрированное CASE-средство должно содержать следующие компоненты:

а) репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хра­нение версий проекта и его отдельных компонентов, синхронизацию поступления информа­ции от различных разработчиков при групповой разработке, контроль метаданных на полно­ту и непротиворечивость;

б) графические средства анализа и проектирования, обеспечивающие создание и ре­дактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели АСОИУ;

в) средства разработки приложений, включая языки 4GL и генераторы кодов;

г) средства конфигурационного управления;

д) средства документирования;

е) средства тестирования;

ж) средства управления проектом;

з) средства реинжиниринга.

Современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых используются практически всеми ведущими западны­ми фирмами.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает их функциональную ориентацию на те или иные процессы ЖЦ.

Классификация по категориям определяет степень интегрированности по выполняе­мым функциям и включает:

а) отдельные локальные средства, решающие небольшие автономные задачи (tools);

б) набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла систем (toolkit);

в) полностью интегрированные средства, поддерживающие весь ЖЦ систем и связанные общим репозиторием.

Помимо этого CASE-средства можно классифицировать по следующим признакам:

а) применяемым методологиям и моделям систем и БД;

б) степени интегрированности с СУБД;

в) доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств.

В настоящее время российский рынок программного обеспечения располагает сле­дующими наиболее развитыми CASE-средствами: ERwin+Bpwin, Designer/2000, Silverrun, S-Designor, CASE-Аналитик, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE.

 

 

 

8. ЗАДАНИЕ НА КУРСОВОЙ ПРОЕКТ И ОБЩИЕ УКАЗАНИЯ ПО ВЫПОЛНЕНИЮ КУРСОВОГО ПРОЕКТА

 

 Курсовой проект представляет собой самостоятельную разработку программной, аппаратной или технологической компоненты АСОИУ.

Основные этапы выполнения курсового проекта являются контрольными заданиями, информирующими преподавателя о ходе изучения курса студентами.

Эти этапы и порядок отчетности о их выполнении сформулированы в конце методического пособия.

Проект включает в себя постановку задачи с представлением предметной области задачи проектирования, анализ существующих или возможных решений поставленной задачи с кратким обзором литературных источников, алгоритмическую проработку решений, выбор среды реализации с использованием средств автоматизации проектирования, как правило, CASE-инструмент. Кафедра предоставляет среды проектирования ERwin, BPwin, Rational Rose.

В курсовом проекте, как правило, должны быть представлены результаты отладки проектируемых компонент в средствах выбранной CASE-среды.

Задание на курсовой проект для студентов заочного отделения выдается, как правило, по тематике предприятия, на котором работает студент.

Тема проекта утверждается в начале семестра на установочных занятиях. Далее, по мере выполнения этапов проекта, студенты в часы консультации представляют материалы проекта преподавателю и в ходе диалога уточняются и формируются соответствующие разделы проекта (допускается использование электронной почты). Целесообразно выделить три основных части проекта, по которым студент должен отчитаться перед преподавателем.  По мере самостоятельного изучения дисциплины «Проектирование АСОИУ» студент выполняет разделы проекта, соответствующие программе курса:

–   постановка задачи, анализ решений и функциональная разработка системы (4-5)–я недели;

–       разработка информационного обеспечения, функциональных модулей, интерфейсов  (10-11)–я недели;

–       отладочные работы, оформление записки, графических материалов и подготовка к защите (14-15)–я недели.

 

 

Структура   курсового проекта

 

 

Объем в стр.

не менее

   1.            Формулировка темы

1

   2.            Анализ аналогичных решений на основании обзора литературы и обоснование выбранного решения

7

   3.            Конструктивно-технологические или теоретические решения, на которых построен проект

5

   4.            Результаты проектирования

15

   5.            Заключение

1

   6.            Литература

1

 

 

Объем пояснительной записки не менее 30 страниц.

 

 

Библиографический список

1.     Вендров А.М. Проектирование программного обеспечения экономических информационных систем. – М.: ФС, 2000.  

2.     Маклаков С.В. Bpwin, Erwin CASE-средство разработки информационных систем.– М.: МИФИ, 1999.

3.     Рогозов Ю.И., Свиридов А.С.  Проектирование  АСОИиУ: Учебное пособие / Под ред. Ю.И. Рогозова. – Таганрог: Изд-во ТТИ ЮФУ, 2007. – 117  c.